This is more for my education, but why introduce a new function here / duplicate the operating system logic for each character? FilePathComparison is an existing static (factory?) that returns the case sensitivity to use. Is there any value is lowering each character individually / vs lowering the entire path outright. rsandbach@d6515d7

The reason is performance. This method can be called a lot, so allocating a string and calling ToLower on it (which allocates another) just gives more for the garbage collector to clean up.

I guess I could have checked if FilePathComparison.Instance returned an Ordinal comparison, rather than copy the code, but it didn't seem like a big deal. Unfortunately the StringComparison type it returns isn't directly useful though. If there was a CharComparison type I would have used it :)

@davidwengier: Is invariant the right approach? After all, file paths are human-readable strings with a potential for important culture details being included in them. Asking because I'm unsure. 🤷

I picked invariant because our existing conversions are Ordinal, which is culture-less, and given there is no ToLowerOrdinal(), avoiding quirks of specific cultures seemed workwhile. I don't claim to be sure of anything though either :)

A couple of suggestions:

1. On .NET Core, consider using the StringComparer.OrdinalIgnoreCase.GetHashCode(ReadOnlySpan<char>) or string.GetHashCode(ReadOnlySpan<char>, StringComparison.OrdinalIgnoreCase) overloads.
2. If converting the span to lower invariant is the way to go, consider calling ReadOnlySpan<char>.ToLowerInvariant(...) rather than calling into a delegate for every char.

Thanks for this. I looked for a method on a comparer that would be useful, but didn't find one. string.GetHashCode will be very helpful

Looks like on .NET Framework, ReadOnlySpan<char>.ToLower..() just does a ToString() then calls ToLower() on it. Since we have to loop anyway, I'm leaning towards leaving this for that TFM. Thoughts?

It's weird because I think CultureInvariant is different from an ordinal comparison. It still does some modifications. I think it still works for our needs though

It's definitely different, but for hash code I don't think we really care much, because there will still be an Equals check once the right bucket is found, and check does use ordinal comparison. In the case of hash code in a dictionary, I think its actually better to err on the side of more collisions, because we can trust Equals.